This section will be a discussion on the architectural and design patterns to be employed in the Warcraft Tower Defense game. There will be a presentation of the patterns used, explaining why the particular pattern was chosen and how we plan to implement it.

\subsection{Architectural and design patterns}
\subsubsection{Model-View-Controller}
The \textbf{Model-View-Controller} (MVC) pattern focuses on separating the domain- or application logic of an application, from the user interface. It consists of tree different structures\cite{wiki:mvc}:
\begin{itemize}
\item \emph{Model} - responsible for managing the behavior of the system. This is where the main functionality and data management of the system should reside.
\item \emph{View} - typically the user interface of the system. Responsible only for drawing or displaying information on screen. The data which is supposed to be shown, is generated and managed in the model.
\item \emph{Controller} - manages input from the user in addition to what should be the following response from the system. An input may instantiate an action for either the model and/or view. 
\end{itemize}
 
A MVC-pattern provides several benefits. In our case the separation of domain logic and user interface provides a solid foundation for supporting the main quality attributes of our system; modifiability and testability. 

If we consider a model responsible for the core functionality of a system, the ability to add a new feature would mainly be concerned with the model of the system, limiting modification to only one module. This way we ensure a loose coupling between the different modules of the system, and thus making it easier to modify a single part of the system. In addition, the MVC-pattern could also help prevent ripple effects which can occur when a module is changed. A change in the user interface would not change anything in the model, and vice versa, a change in one of the methods of the models would not interfere with the user interface, as long as the method still returns the same type of value. 


The testability-aspect also benefits greatly of the isolation of domain logic, especially when considering unit testing of a system. A unit-test should not have to be concerned with what happens in the user interface, it should only focus on the behavior of the domain logic. What happens when a user press a button at the user interface should not be the unit tests responsibility. Tests concerning dependency and communication between modules would be more of an integration test's responsibility. 


With unit testing, the model will again be the main focus point. Unit test can be applied to only the model of the system. If a test would require user input to test a certain function, the tests-classes should be responsible for generating mock values to simulate user input. In this way, the functionality can easily be tested in isolation and with no dependency of the user interface. We should however assume that some form of design patterns and principles within the model are being practiced.


For our tower defense game, we have implemented the MVC pattern for a particular aspect of the system; the towers the player can build to shoot down the enemies. We decided to employ the MVC to this particular area of the game due to the various attributes of the towers. A tower has a defined set of properties such as the amount of damage it can inflict on the enemies, a particular range, as well as a set of images for the representation of the tower on the screen. Consequently, these values are set and manipulated in a tower's model. 

To show a tower on the screen, a TowerSprite-object is created. The TowerSprite belongs to the view-structure of the MVC; it draws a tower on the screen. A TowerSprite recieves a model as a parameter in its constructor (of type AbstractTowerModel -- more elaborated later in the section), and the behavior of the tower is decided by this model. Both the tower-view and model is manipulated through the GameController-object, which (obviously) acts as the controller in this case. The controller decides when and at which enemy the tower should shoot, depending on the proximity of an active enemy.

The Tower-MVC is implemented in a way which supports the modifiability quality requirement. In the current version of the game, only 4 different towers can be built. However, if it is desired to add a new tower to the list of buildable towers, it is only neccesary to implement a new model implementing the AbstractTowerModel. The AbstractTowerModel is a simple interface with a few defined methods for a tower, and is the interface a TowerSprite recieves as the constructor parameter. 

Testability is also supported by placing most of the logic in the model, which can be tested independently of other application components. To test the behavior of a tower displayed on the screen, it might be necessary to run the entire program to test one detail. On the other hand, when implementing the functionality in the model, a test-class can test the behavior of the tower directly from the model.

\subsection{Abstract factory}

The abstract factory pattern concerns the creation of objects. The main idea is that it provides an interface for the creation of related objects, without specifying the concrete classes. A normal way of incorporating this pattern would be to create a concrete implementation of an abstract factory, which creates concrete classes, and letting the client code be unaware of the concrete implementation, all it needs is an object implementing the abstract factory. \cite{wiki:abfac}  

In our case, the abstract factory is useful when creating similar objects. An example of this is the model-objects required for TowerSprites. As explained in the previous section, an implementation of AbstractTowerModel includes methods for a towers behavior. In turn, we created the AbstractTowerModelFactory interface, which various TowerModel-factories will implement. The diagram gives an example of how the creation of AxeThrowerModels is created. The factory implements the interface and creates concrete objects which implement a specific interface -- the return type of the factory. This way, the client code need not know of the concrete implementation of tower-model, only that it implements the AbstractTowerModel interface.


